Let me gather more context about the trace ID generation and validation.

Let me check one more aspect about the trace context generation.

Trace header implementation is properly validated

The TRACE_ID validation is handled by the Micrometer tracing framework through TraceContext builder in ObservationHelperImpl. The framework ensures W3C trace context compliance, making additional validation in RTSCaller unnecessary.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for TRACE_ID format validation or generation in the codebase
rg -g '!*.{log,lock}' -A 3 "TRACE_ID.*format|TRACE_ID.*generate|TraceContext"

Length of output: 1208

Script:

#!/bin/bash
# Look for TRACE_ID usage and generation in ObservationHelperImpl
ast-grep --pattern 'class ObservationHelperImpl {
  $$$
  $_($$) {
    $$$
    TRACE_ID
    $$$
  }
  $$$
}'

# Check for any trace ID format constants or validation
rg -g '*.java' -B 2 -A 2 'TRACE_ID.*=|TRACE_ID.*pattern|W3C.*trace'

Length of output: 941

Script:

#!/bin/bash
# Look for the traceContextBuilder implementation and usage
rg -g '*.java' -B 3 -A 3 'traceContextBuilder|TraceContext.*build'

# Check if there's any validation in RTSCaller
ast-grep --pattern 'class RTSCaller {
  $$$
  makeRequest($$$) {
    $$$
  }
}'

Length of output: 1183

Let me check if this constant is still being used in the codebase.

Custom traceparent handling has been properly removed

The only remaining references to traceparent are:

• A commented-out block in RTSCaller.java
• An unused constant definition in MDCConstants.java

Since the code is already commented out and the constant is not being used anywhere else in the codebase, the removal of custom traceparent handling is complete. The new ObservationRegistry integration will handle the tracing properly.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining traceparent header manipulations
rg -i "traceparent" --type java

Length of output: 187

Script:

#!/bin/bash
# Search for usages of TRACE_PARENT constant
rg -A 3 "TRACE_PARENT" --type java

Length of output: 1127

Let me gather more information about the tracing configuration to better understand the impact.

Let me check the OpenTelemetry configuration to understand the sampling setup.

Span filtering removal is safe to proceed

The change to return all spans is aligned with standard OpenTelemetry practices. The system uses OpenTelemetry SDK with configurable sampling through environment variables, so trace volume can be controlled at deployment time without code changes. Previous custom filtering was likely redundant with modern observability platforms' capabilities.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any span volume configurations or sampling rates in the codebase
rg -i "sampling.*rate|span.*filter" --type java

Length of output: 449

Script:

#!/bin/bash
# Check for tracing configuration and sampling related code
rg -i "tracingconfig|samplerconfig|opentelemetry.*sampler" --type java

# Look for any other span filtering or processing logic
ast-grep --pattern 'class $_ implements SpanProcessor { $$$  }'

# Check for any trace exporter configurations
rg -i "trace.*export|opentelemetry.*export" --type java

Length of output: 1627

Script:

#!/bin/bash
# Check OpenTelemetry configuration and initialization
rg -i "opentelemetry.*sdk|tracerprovider|sdktraceprovider" --type java -A 5

# Look for any application properties related to tracing
fd -e properties -e yaml | xargs rg -i "trace|opentelemetry|otel"

Length of output: 3542

Property configuration verified and correctly mapped

The new property path appsmith.observability.metrics.enabled is properly defined in application.properties and mapped to the environment variable APPSMITH_MICROMETER_METRICS_ENABLED with a default value of false.

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the new property exists in application properties files
# Expect: Property should be defined in at least one properties file

rg "appsmith\.observability\.metrics\.enabled" -g "*.properties"

Length of output: 219

Property namespace changes are properly reflected in application.properties

The verification confirms that:

• All new observability namespace properties are correctly defined in application.properties
• No legacy micrometer namespace properties remain in the properties files
• Environment variable mappings are preserved

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if the new property names are defined in application properties
# and if there are any remaining old property references

echo "Checking for new property definitions..."
rg "appsmith\.observability\.(metrics|tracing)" -g "*.properties"

echo "Checking for any remaining old property references..."
rg "appsmith\.micrometer\.(metrics|tracing)" -g "*.properties"

Length of output: 961

Properties are correctly defined in application.properties

Both properties are properly configured with default values:

• appsmith.observability.deployment.name defaults to "self-hosted"
• appsmith.observability.service.instance.id defaults to "appsmith-0"

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify property definitions in application.properties
rg "appsmith\.observability\.(deployment\.name|service\.instance\.id)" -g "application*.properties"

Length of output: 384

Service name is correctly used in OpenTelemetry configuration

The service name "appsmith-client" is properly used in the client-side OpenTelemetry configuration and is consistent with the tracing setup. The service name is used as a resource attribute following OpenTelemetry semantic conventions (ATTR_SERVICE_NAME).

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for references to the service name in trace/observability related code
rg -l "appsmith-client" | grep -i "trace\|observ\|telemetry"

# Search for other potential service name definitions
rg -l "serviceName.*appsmith.*client" 

Length of output: 135

Script:

#!/bin/bash
# Let's search for any trace/telemetry configuration or initialization code
rg -A 5 "initializeSentryTracing|initializeTracing|initializeTelemetry" 

# Search for any trace/span related code that might use service names
rg -A 3 "createSpan|startSpan|tracer\.start" 

# Look for any OpenTelemetry related imports and configurations
rg -A 2 "@opentelemetry|opentelemetry"

Length of output: 48755